IPv6 addresses are 128 bits in length. The first 64 bits of an address form a routing prefix which uniquely identifies the Internet access node (or so-called “local link”) used by an IP terminal or node, whilst the last 64 bits form a host suffix which uniquely identifies the mobile terminal to the access node (or within the local link) The host suffix is referred to as an “interface identifier” as it identifies the host uniquely over the access interface. Typically, when a host registers with an access node, the host learns the routing prefix of the access node from an advertisement message sent from the access node. According to IETF RFC3041, a host then generates its interface identifier using a random number generated by the host. The host may additionally use a link layer address to generate the interface identifier, the link layer address being for example a MAC layer address used by the access network.
WO02/076060 describes how a node can generate a cryptographic version of the interface identifier using a one-way coding function, such as a hash function, and provide this to another peer user, who can then verify that the node is the owner of the interface identifier part of the IP address. Such cryptographically generated addresses are known as CGAs. CGAs provide a level of security to help prevent, for example, a denial of service attack, in which the attacker claims to be the owner of the IP address that the node wishes to use. The CGA approach has been standardised in IETF RFC3972 and is used inter alia in the Secure Neighbor Discovery (SeND) protocol standardised in IETF RFC 3971.
According to RFC 3972, CGAs are generated as follows:                Hash1=hash(modifier|prefix|public key|extensions)        IPv6 address=prefix|Hash1 (with certain bits set according to security level and other requirements).        
Where “prefix” is the network routing prefix, “hash” is a cryptographic hash function (SHA-1), “public key” is a public key of the node generating the address, and “extensions” is a currently unused field for carrying standardised information. The “modifier” is a 128 bit value generated by the node to both increase security and enhance randomness. More particularly, depending upon the required security level, a modifier value is selected that results in a certain concatenation of data (including the modifier and the public key) hashing to a value (“Hash2”) which has a specified number of “0”s in the leftmost bit positions.
In order to prove ownership of a CGA, a node must be able to provide a certificate containing the Interface Identifier (IID) part of the CGA address, the modifier, public key, and any extension, arranged as a CGA data structure. The certificate contains a digital signature (SHA-1) taken across the message to be sent (concatenated with a 128-bit CGA type tag) using the node's private key. A peer node receiving the certificate first computes Hash2 and verifies that it has the correct number of “0”s in the leftmost bit positions. If this is the case, it computes Hash1 and compares this to the IID, thereby verifying that the IID belongs to the public-private key pair, and then verifies the signature by reversing the signing process using the verified public key. This second step proves that the sender actually owns the public key and has not merely misappropriated it, as well as proving that the message originated from the claimed sender.
A host owning a CGA (the “delegating” node) may delegate responsibility for that address to some further node (the “delegated” node), for example to allow the delegated node to request that traffic be directed to the delegating node. This is achieved by providing the delegated node with a certificate containing the CGA, the CGA data structure, an identity of the delegated node, and a signature created using the delegating node's private key. In order to prove to a third party that it is allowed to use the claimed CGA, the delegated node provides the certificate to the third party which is able to verify that the IID belongs to the public key, and that the certificate is validly signed by the owner of the public key. In the case where said identity is the delegated node's public key, the delegated node may sign any request relating to the CGA with its private key, thus allowing the third party to prove that the delegated node owns the claimed identity.
A problem with this approach to delegation is that the certificate provided by the delegating node to the delegated node is tied to a single CGA. In the event that the delegating node changes its IPv6 address, e.g. due to mobility and its use of a new network routing prefix, a new certificate must be provided to the delegated node.